[アップデート]Security HubのCIS AFB v1.2 コントロール3.2の評価ロジックが拡張されました

#AWS Security Hub

#AWS

杉金晋

2021.12.04

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

みなさんこんにちは、杉金です。

小さなアップデートですが、CIS AWS Foundations Benchmark v1.2 コントロール3.2の評価ロジックが拡張されました。何が変わったのかと設定方法について紹介いたします。

コントロール3.2の内容

多要素認証（MFA）で保護されていないAWSコンソールへのログインを検知する仕組みがあるかをチェックするものです。検知するための具体的な仕組みとしては、CloudTrailでコンソールログインイベントを記録して、CloudWatch Logsに連携してMFAで保護されていないログインをCloudWatchアラームで検知させます。

AWS Security Hubのユーザーガイド：Control3.2 Remediation

アップデート内容

今回のアップデートは以下リンクのAWS Discussion Forumsで発表されたものですが、re:invent2021で発表されたAWS re:Postに今後投稿ページが移管される可能性があるため、投稿内容を引用します。

To reduce the number of false positives on the CIS AWS Foundations Benchmark v1.2 control 3.2, we have expanded the evaluation logic. CIS 3.2 now can accept both metric filters below:

{ ($.eventName="ConsoleLogin") && ($.additionalEventData.MFAUsed !="Yes") }

{ ($.eventName = "ConsoleLogin") && ($.additionalEventData.MFAUsed != "Yes") && ($.userIdentity.type = "IAMUser") && ($.responseElements.ConsoleLogin = "Success") }

Previously, only the first metric filter was accepted, which created false positives if you are using MFA through a SSO provider (e.g., via Okta or AWS SSO). The additionalEventData.MFAUsed field does not account for MFA via SSO providers. The second metric filter that is now acceptable scopes down the control to PASS if you are using the metric filter to only look at console login events associated with an AWS IAM user.

引用元：https://forums.aws.amazon.com/ann.jspa?annID=9033

従来の評価方法では、SSOプロバイダー（OktaやAWS SSOなど）を介してMFAを使用している場合に誤検知が発生していました。今回の新たな評価ロジックにより誤検知を防ぐことができます。

試してみる

投稿内容に記載のあった新たな評価ロジック（以下）を使って設定を行い、検知するかの確認とコンプライアンスのステータスが成功になることを確認します。

{ ($.eventName = "ConsoleLogin") && ($.additionalEventData.MFAUsed != "Yes") && ($.userIdentity.type = "IAMUser") && ($.responseElements.ConsoleLogin = "Success") }

設定方法

CloudTrailの設定

CloudTrailの証跡からCloudWatch Logsの設定を行います。対象の証跡にあるCloudWatch Logsの項目から「編集」を選択します。

CloudWatch Logsに連携するための設定を行います。設定が終わりましたら「設定の保存」を選択します。

CloudWatch Logsの設定

続いてはCloudWatch Logsの設定です。対象のロググループを選び、メトリクスフィルターを作成します。

「フィルターパターン」に評価ロジックを貼り付けます。

任意のフィルター名を決めます。

CloudWatchメトリクスの設定を決めます。名前はお好みで、メトリクス値はMFA無しのログインに一致したらカウントされるよう「1」を設定します。一致しない場合のデフォルト値は「0」にします。

後は下にスクロールして「Next」を選択します。

試しにMFA無しのテストIAMユーザを作りログインしてみると、CloudWatchメトリクスにカウントされることを確認できました。

CloudWatchアラームのの設定

対象のメトリクスを選んだ状態で「グラフ化したメトリクス」タブを選び、ベルアイコンを選んでCloudWatchアラーム作成の画面に移動します。

アラームの設定を決めていきます。期間内に1回でもMFA無しログインを検知するよう、統計を平均から最大に変更します。

MFA無しログインを1回でも検知するよう条件を「以上」にして、しきい値を「1」にします。

条件に一致したら異常とするため「アラーム状態」を選びます。通知先のSNSトピックを選択します。

あとはそのままスクロールして「次へ」進みます。

アラーム名は任意の名前をつけます。

設定のプレビューを確認して「アラームの作成」を選択します。

CloudWatchアラームから全てのアラームを選んで作成したアラームが存在することを確認します。また、この時にもテストIAMユーザでログインしてみてメール通知されるところまで確認します。

ログイン後にアラーム状態となり、メールも飛びました。（メール受信画面は割愛）

Security Hubのステータス確認

SecurityHubのコンプライアンスのステータスを確認します。

設定前のコントロール3.2のステータス

設定後のコントロール3.2のステータス

ステータスが成功に変わりました。設定後に即時反映される訳ではないため、再スキャンを気長に待ちましょう。

どのくらいの間隔でスキャンされるかは以下のページをご確認ください。
AWS Security Hubユーザーガイド：セキュリティチェックの実行スケジュール

設定、動作確認までの一連の流れは以上となります。

最後に

今回はSNSによる通知だけでしたがCloudWatchアラームのアクションでSSMのインシデントに追加することも可能です。基本的にIAMポリシーでMFAを強制するようにしていても、何らかの理由でポリシーが適用されていないIAMユーザーがいたり、設定忘れに気づく手段としてこのコントロールは有効だと思いました。CloudTrailの証跡をCloudWatch Logsに連携して利用料にどれくらい影響を与えるかは意識しておいた方が良さそうです。